Forum:Is there a Google Maps guru reading this?
If you also happen to be a Virtual Skipper fan then your expertise is badly needed here. If you are not a Virtual Skipper fan then I could use some advice/assistance with setting up for display of so-called Track images. These are aerial maps of race courses for sailboats. See example below. Problem statement This wiki can expect to see several hundred to a few thousand track articles created. It is my hope that all of these can be created semi-automatically based on a handful of key data extracted from rather small (<< 100kB) '.'''Gbx files named after each track. One of the more useful pieces of "information" about each track to be displayed at this wiki is an aerial view of the race course. This aerial view shows at one glance the locations of a start line, several marks and/or gates along the course and a finish line together with a continuous line (including arrowheads) that trace out a path from start line to finish line and clearly illustrates the order and direction that each mark is to be rounded from start to finish. It is not illustrated by this example but sometimes the same mark may be rounded a second time on a subsequent leg of the race. This complicates the tracing of a path around the course. * Note that this vital data is presented using about 5 or 6 solid colors. That fact may prove useful later on. * There are between 16 and 20 venues where these race courses may be constructed. The 3D world data for 16 of those venues is packaged with the VSK game client. The developer has already given permission for screen shots and derivative images to be freely used at this wiki. ** The approximate area of each venue is 3200x2400 pixels at full zoom out and 22400x16800 pixels at full zoom in. (The magnification seems to be 7 times.) * Some race courses will use a wide area of the chosen venue however most use only a modest fraction of that area e.g. 400x300 pixels Now the problem is that even if a modest 400x300 pixel .png image file is used to illustrate each track then the image file alone will be not quite two orders of magnitude (100x) larger (in bytes) than the raw .Gbx file. The same venues are used over and over again just with a different layout of marks and therefore a different race course. It seems terribly wasteful (not to mention tedious) to require a resized/resampled screen shot for each article describing a track. The raw data for the image at right can be distilled down to * 8 coordinate pairs for 8 buoys/marks, * 2 items of binary data for which side (port/starboard) of your boat the 2 solitary buoys are to be rounded and * 4 directional arrows for the 4 legs of the race. Preferred solution A better solution than uploading several hundred or a thousand images (possibly with aspect ratio differences from one article to the next) would be to: # fracture each of the 3D world venues into say, 256x256 pixel tiles # upload these ~130 tiles (or ~6500 tiles at maximum zoom in) per venue (16 venues) to Wikia. This type of thing has been done for another game wiki already. (see: w:c:rappelz:Places and a polygon example at w:c:rappelz:Category:Mobs_by_location:_East_of_1st_Valmore_Mine User Drennan was the architect behind that effort.) # at each Track page upload the raw data (i.e. about a dozen number for the example above) # construct (or upload) a transparent background overlay using the 5 or 6 colors referenced earlier to graphically illustrate that path around the buoys. #:This is no trivial piece of vector graphics however I suspect that for an engineer/programmer with the right skill set it is a piece of cake. #:* If, from experience, you know that this level of icon plotting and line/curve drawing is beyond the capability of markers and polylines then please advise and save me the frustration of learning the hard way. #:* An arc radius of 20-30m would be satisfactory, 5-10m radius would be ideal. # combine this this vector graphics overlay with a Google Map view of that portion of the 3D world where the course has been charted I most likely glossed over some of the more complex detail but in very broad terms that is the design goal. I've seen all but step 4 implemented successfully at rappelz.wikia.com so I am certain that 4/5 pieces of the plan are realistic. Many years ago I worked with an engineer who was adept with adobe postscript vector graphics and based on my experience using his in-house developed utility to create rather complex timing diagrams I suspect that the vector graphics described by step 4 is also realistic .. I just don't know how challenging (read: time consuming) it might be. ;Pros and cons * The benefit from this tiled approach should kick in at around the 50th track uploaded for the same venue. At that point the pixels uploaded using the screenshot approach begin to surpass the pixels uploaded for the entire set of tiles for that one venue. * The only downside I can see is that any vessels the track designer placed as obstacles will not appear in the aerial view. I think that is a small trade off. So if this describes a problem that you've already solved elsewhere or know of someone who has solved it elsewhere then please contact me to offer either a helping hand or advice. I don't mind doing some heavy lifting so long as I know the person directing my effort has a clear vision of the path to success. --najevi 10:44, 15 August 2009 (UTC) Possible coordinate system If pixel based coordinates follow the standard where the (0,0) origin is at the top left corner of the master map image then a coordinate pair of (-1,-1) can be used to identify a port rounding while a coordinate pair value of (-1,1) can identify a starboard rounding. Therefore every mark on the course can be adequately described by just two coordinate pairs (i.e. 4 numbers). Gates, start and finish lines need two coordinate pairs because each of these require the position of two buoys to be specified but do not need port/starboard rounding to be specified. Regardless of what coordinate system comes out of the Track.Gbx file a translation to the above system will be performed before GoogleMaps display of the track is computed. --najevi 06:31, 16 August 2009 (UTC) Lazyman's solution I've been giving some thought to how illustration of a track/course at this wiki might emulate the way in which the path around the marks on a course are illustrated within the game client. (i.e using a yellow line representing the wake of a boat as it sails the course) Given enough time and effort I am confident that this "taut string" method can be implemented however an expedient, alternative solution is described below to invite discussion. A quick and dirty solution for illustrating: #which order to round the marks #which way to round a mark #which pairs of buoys represent gates, start and finish lines might be to use alphanumeric labels at each mark: :S for start :F for finish :1,2,3,4, ... in between S and F marks to identify the order (i.e. same as the leg number) That number can be color-coded: :red when a mark must be left to port :green when a mark must be left to starboard :white (on dark blue water background) when a pair of marks is a gate and must be sailed through. Gates are always entered from the direction of the preceding mark. When a mark is used on multiple legs then these alphanumeric labels will be arranged side by side such that the number sequence is always in ascending order. -- najevi 07:42, February 8, 2010 (UTC)